1. Technical Field
The present invention relates to a system and a method to allow one, two or more parties to model and share knowledge, in particular structured knowledge along with the possibility to use whole or part of this model in or with a computer executable artifact.
2. Description of Related Art
Open source projects reduce the cost of development but the integration work is still important as initiatives in this area are quite scarce, are using different languages, different coding conventions, different technical infrastructures and are focused on code rather than high-level knowledge models.
From a global perspective, there is a lot of work duplication in the way one builds administrative, commercial, financial and generally most structured data-oriented application. For instance the business logic of a specific income tax exemption is probably coded in the tax administration software itself of course and in dozens of commercial software used by taxpayers. Moreover it may be coded in different implementation languages.
From a global perspective, there is also a lot of structured data duplication between privately or publicly held databases or file systems. Synchronization between those data repositories is mostly nonexistent. This usually requires a lot of efforts, time and energy waste to maintain up-to-date data, build appropriate and dedicated replication mechanisms when possible. There is however a growing need of connecting systems.
As far as structured data are concerned, connectivity between people, companies and administration is quite limited. Creation of web services between parties is still cumbersome, of limited usability and is relatively expensive. The methods to define mapping between data show low reusability.
The existing ontologies, taxonomies or knowledge systems are often limited to static knowledge description or have not shown sufficient versatility and ease of use to allow large-scale usage or integration in information systems.
Customizing knowledge in the current modeling methods and systems is not possible or very limited. Therefore the possibility to share and reuse knowledge is greatly constrained.
Automation of software production requires strong ability to integrate usage data, e.g., the way one is going to use the knowledge model, the data defined or derived from this knowledge model. This usage data, beside general knowledge, is a key element to be able to automate parts of a software design.
Automation of software production requires also a set of ontological information that is usually missing from the usual models used to produce software because it is usually too costly to formalize this information or interact with ontological systems.
Mainstream Modeling Methods are based on a single point of view on a business domain. Thus if one needs to connect the information system built from the model to another existing information system, one is usually forced to use other techniques or methods to define the collaboration between the two systems, through data mapping methods, services or API definition.
Let us take a comparison for clarifying this. Let us say that Juan is a native Spanish speaker. Juan is able to communicate effectively with any member of the Spanish speaking community, and express ideas, opinions, exchange information, etc., with a set of words that are well-known for the members of his linguistic community. If Juan has to talk to Natacha, a Russian speaker, he will have to buy a Spanish-Russian dictionary. And if he has to talk to a Japanese speaker, he will have to get a Spanish-Japanese dictionary.
Building an information system follows the same pattern. One first builds a model, e.g., a kind of community language, and the information system through a local point of view (a company, organization, part of an organization, etc.); then one builds later the interface or the data mapping to make the system able to communicate with another one.
However a major difference between the human communities and the information system models is in the number and the size of the communities: a linguistic community may have millions of members and there are about 2,000 active languages around the world. On the other hand knowledge models are usually built for a company or a company department, so there are millions of them, and they are used by people in the hundreds or in the thousands through an information system. Therefore the communication tools are far more important in the case of information system models. Establishing a communication protocol between information systems is a specific task, e.g., it usually implies a dedicated work for each couple of information systems. Note that in some cases an industry-wide initiative has led, usually after a long process, to a common communication protocol; the data mapping task relates then to the mapping from an internal model to the industry standard. And as these information systems have been built from separate models, the cost of the definition of the communication protocol is very high.
Let us explain the “data vs. metadata” concept. Historically the design of large software has followed a layer pattern. Code and tools for building, as well as managing that code, are built around a specific layer. For example, in a data-oriented application, one of these layers can be a database and tools exist to manage the design and the administration of this database layer.
One is able today to change seamlessly any data in a database-oriented application. Changing the schema of this database, that is the metadata, is a part of the software engineering discipline and usually requires another tool, managed by technical people. To cope with the lack of flexibility of this approach one has created data structures where part of their definition, part of the metadata, is left to the user as a customizable item. Off-the-shelf software uses this technique to allow some specific customization for their customers.
In addition to increased complexity, this usually leads to a performance loss as this translates technically into an additional indirection level. The same holds for business rules.
As business is ever changing and corporations need to react more quickly, better change management techniques are needed. However tools to manage metadata at different layers are already in place. These tools are thus now extending their functionality to be able to dialog with other tools. This has several drawbacks:                metadata are scattered in several tools so that discrepancies are frequent;        metadata are mainly handled by technical people, separated from the business department where the data themselves are created and used. Thus the change process remains heavy.        
To carry on with our comparison, Juan may extend the knowledge of his mother tongue by using a Spanish dictionary with word definitions, synonyms, etc. In a dictionary, words are defined using other simpler words. Those simpler words have different roles: in some use cases they describe something, in other they help to describe other words. The same holds in information systems: what is considered to be metadata from a point of view is data from another point of view.
Since the nineties, an effort has been undertaken to unify and standardize the semantics and notation in object-oriented modeling languages. This standard is known under the name UML (Unified Modeling Language). UML is a standard language for specifying, visualizing, constructing and documenting the artifacts of software systems as well as business modeling. The industry looks for techniques to automate the production of software, to improve quality and reduce cost and time-to-market. Businesses also seek techniques to manage the complexity of systems as they increase in scope and scale. In particular, there is a need to solve recurring architectural problems. Additionally the development of the internet, while making some things simpler has exacerbated these architectural problems. UML was designed to respond to these needs.
A UML model is based on class diagrams. A class is an entity of a given system which encapsulates implementation of business functionality. A class is a named representation of objects or entities which comprise attributes (properties, features) and methods (what the objects do). In another approach a class has a name and responsibilities. Classes form the main building blocks of an object-oriented application. Objects are associated with or related to other objects. Associations are modeled as bidirectional lines connecting the two classes whose instances are involved in the relationship. Other useful relationships between classes have been defined: multiplicity, directed association (unidirectional), aggregation, composition, inheritance/generalization, realization, etc. Particularly inheritance is an interesting mechanism taking advantage of similarities often existing between different classes and permitting not to write the same code repeatedly.
In UML, a “method” or “function” is attached to a “class”. Software engineers may often hesitate between encapsulation in a class or another one (or to create a specific class for this purpose). The semantics of the method, dependencies between classes are decision factors. Changes may affect negatively past design decisions and force the software engineer to redesign part of his software. Design pattern have been created to try to cope with this issue by providing flexible design for aspects that are supposedly subject to change.